ワイヤレス通信システムにおけるハンドオーバの間に順序が狂っているパケットを取り扱うための方法および装置

专利摘要:
ハンドオーバの間にパケットを送り、同期を維持するための技術を記述する。ソース基地局からターゲット基地局に、ユーザ機器（ＵＥ）をハンドオーバしてもよい。ソース基地局は、ＵＥに対するパケットをターゲット基地局に転送してもよく、ターゲット基地局は、順序が狂ってパケットを受信するかもしれない。１つの設計において、ターゲット基地局は、各パケットをＵＥに順に送ることができるかどうかを決定し、順に送ることができる場合、パケットを送信し、そうでない場合、パケットを廃棄してもよい。別の設計において、ターゲット基地局は、再順序付け窓内で受信したパケットを再順序付けしてもよく、再順序付けしたパケットをＵＥに送ってもよい。
公开号:JP2011505758A
申请号:JP2010536121
申请日:2008-11-25
公开日:2011-02-24
发明作者:メイラン、アルナード
申请人:クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ；
IPC主号:H04W36-02

专利说明:

[0001] 本出願は、いずれも“ハンドオーバにおけるターゲットアクセスポイントおよびユーザ機器間のハイパーフレーム番号同期を維持するための方法および装置”と題し、本出願の譲受人に譲渡され、参照により明白にここに組み込まれている、２００７年１１月２７日に出願された米国仮特許出願シリアル番号第６０／９９０，５８９号と、２００７年１１月２８日に出願された米国仮特許出願シリアル番号第６０／９９０，９０６号とに対する優先権を主張する。]
分野

[0002] 本開示は一般に通信に関し、より詳細には、ワイヤレス通信システムにおいてパケットを送信する技術に関する。]
背景

[0003] ワイヤレス通信システムは、音声、ビデオ、パケットデータ、メッセージング、ブロードキャストなどのような、さまざまな通信コンテンツを提供するために広く展開されている。これらのワイヤレスシステムは、利用可能なシステムリソースを共有することによって複数のユーザをサポートできる多元接続システムであってもよい。そのような多元接続システムの例は、コード分割多元接続（ＣＤＭＡ）システムと、時分割多元接続（ＴＤＭＡ）システムと、周波数分割多元接続（ＦＤＭＡ）システムと、直交ＦＤＭＡ（ＯＦＤＭＡ）システムと、単一搬送波ＦＤＭＡ（ＳＣ−ＦＤＭＡ）システムと含む。]
[0004] ワイヤレス通信システムは、多数のユーザ機器（ＵＥ）に対する通信をサポートできる、多数の基地局を含んでもよい。ＵＥは移動性体であってもよく、ＵＥがシステムに関して移動するとき、ソース基地局からターゲット基地局にハンドオーバされてもよい。ハンドオーバの間に、ソース基地局は、無事にＵＥに送られていないデータのパケットを有するかもしれない。ハンドオーバの間に、これらのパケットをＵＥに適切に送ることが望まれるかもしれない。]
概要

[0005] ハンドオーバの間にパケットを送り、同期を維持するための技術を記述する。ソース基地局からターゲット基地局に、ＵＥをハンドオーバしてもよい。ソース基地局は、ＵＥに対するパケットを有していてもよく、これらのパケットをターゲット基地局に転送してもよい。ターゲット基地局は、例えば、ソース基地局とターゲット基地局との間のインターフェースのパケット交換の性質に起因して、順序が狂ってパケットを受信するかもしれない。ターゲット基地局が、順序が狂っているパケットをＵＥに送る場合、同期損失が生じるかもしれず、および／または、ＵＥがパケットを回復できないかもしれない。]
[0006] １つの設計において、ターゲット基地局は、ソース基地局によって転送された各パケットをＵＥに順に送ることができるかどうかを決定してもよい。各パケットは、その順序を決定するために使用してもよいシーケンス番号を有していてもよい。ターゲット基地局は、転送された各パケットのシーケンス番号と、ＵＥに送られた最後のパケットのシーケンス番号とに基づいて、転送された各パケットをＵＥに順に送ることができるかどうかを決定してもよい。ターゲット基地局は、順に送ることができる各パケットを送ってもよく、さもなければ、パケットを廃棄してもよい。ＵＥによって廃棄されるパケットを送らないことによって、無線リソースを節約してもよい。]
[0007] 別の設計において、ターゲット基地局は、再順序付け窓内でソース基地局から受信したパケットを再順序付けしてもよく、再順序付けしたパケットをＵＥに送ってもよい。ソース基地局からの最初のパケットを受信すると、ターゲット基地局は、タイマを開始してもよい。ターゲット基地局は、最初のパケットが順序が狂って受信される場合、そのパケットをバッファに入れてもよい。ターゲット基地局はまた、タイマが満了する前にソース基地局から順序が狂って受信したすべての後続のパケットをバッファに入れてもよい。タイマの満了後に、ターゲット基地局は、バッファに入れられているパケットを再順序付けして送ってもよい。再順序付け窓は、時間の期間またはシーケンス番号の範囲をカバーしてもよい。]
[0008] さらに別の設計において、ターゲット基地局は、ソース基地局からパケットを順序が狂って受信してもよく、パケットが順であるかのようにパケットを処理してもよい。ターゲット基地局は、順序が狂っているパケットに起因して、ハイパーフレーム番号（ＨＦＮ）をインクリメントしてもよく、インクリメントされたＨＦＮと、パケットのシーケンス番号とを含むカウントによりパケットを暗号化してもよい。代替として、ターゲット基地局は、最後に送られたパケットのシーケンス番号よりも後のシーケンス番号でパケットを再割り当てしてもよい。いずれにしても、ＵＥは、パケットを正しく解読し、同期損失を回避できる。ＵＥにおける上位レイヤは、パケットの再順序付けを実行してもよい。]
[0009] ここで記述する技術は、上述したように、ＵＥのハンドオーバの間に、ソース基地局からターゲット基地局に転送されるパケットに対して使用してもよい。一般に、本技術は、第３のエンティティ（例えば、ＵＥ）への送信のために、第１のエンティティ（例えば、ソース基地局またはサービングゲートウェイ）から第２のエンティティ（例えば、別の基地局）に送られるパケットに対して使用してもよい。パケットはシーケンス番号を有していてもよく、第２のエンティティにより順序が狂って受信されてもよい。第２のエンティティは、上述した設計のいずれかを使用してパケットを処理してもよい。]
[0010] 本開示のさまざまな観点および特徴を、以下でさらに詳細に説明する。]
図面の簡単な説明

[0011] 図１は、ワイヤレス通信システムを示す。
図２は、システム中の異なるエンティティに対するプロトコルスタックの例を示す。
図３は、ハンドオーバに対するコールフローの例を示す。
図４は、ハンドオーバの間のデータ送信およびデータ転送を示す。
図５Ａは、送信エンティティにおける暗号化を示す。
図５Ｂは、受信エンティティにおける解読を示す。
図６Ａは、暗号化および解読に対して使用されるＣＯＵＮＴパラメータを示す。
図６Ｂは、シーケンス番号空間を示す。
図７は、パケット廃棄をともなう、パケットを送るプロセスを示す。
図８は、パケット廃棄をともなう、パケットを送る装置を示す。
図９は、再順序付けをともなう、パケットを送るプロセスを示す。
図１０は、再順序付けをともなう、パケットを送る装置を示す。
図１１は、強制的な順序付けをともなう、パケットを送るプロセスを示す。
図１２は、強制的な順序付けをともなう、パケットを送る装置を示す。
図１３は、パケットを受信するプロセスを示す。
図１４は、パケットを受信する装置を示す。
図１５は、ＵＥおよび２つの基地局のブロック図を示す。] 図１ 図１０ 図１１ 図１２ 図１３ 図１４ 図１５ 図２ 図３ 図４
詳細な説明

[0012] ここで記述する技術は、ＣＤＭＡや、ＴＤＭＡや、ＦＤＭＡや、ＯＦＤＭＡや、ＳＣ−ＦＤＭＡや、他のシステムのような、さまざまなワイヤレス通信システムに対して使用してもよい。用語“システム”および“ネットワーク”は、区別なく使用されることが多い。ＣＤＭＡシステムは、ユニバーサル地上無線アクセス（ＵＴＲＡ）、ｃｄｍａ２０００などのような無線技術を実現してもよい。ＵＴＲＡは、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）と、ＣＤＭＡの他の変形体とを含む。ｃｄｍａ２０００は、ＩＳ−２０００、ＩＳ−９５およびＩＳ−８５６の標準規格をカバーする。ＴＤＭＡシステムは、移動体通信用グローバルシステム（ＧＳＭ）のような無線技術を実現してもよい。ＯＦＤＭＡシステムは、進化型ＵＴＲＡ（Ｅ−ＵＴＲＡ）や、ウルトラモバイルブロードバンド（ＵＭＢ）や、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）や、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）や、ＩＥＥＥ８０２．２０や、フラッシュ−ＯＦＤＭ（登録商標）などのような無線技術を実現してもよい。３ＧＰＰロングタームエボリューション（ＬＴＥ）は、Ｅ−ＵＴＲＡによって規定されるエアインターフェースと、Ｅ−ＵＴＲＡＮによって規定されるネットワークアーキテクチャとを利用する。Ｅ−ＵＴＲＡは、ダウンリンク上でＯＦＤＭＡを用い、アップリンク上でＳＣ−ＦＤＭＡを用いる。ＵＴＲＡ、Ｅ−ＵＴＲＡ、Ｅ−ＵＴＲＡＮ、ＬＴＥおよびＧＳＭは、“第３世代パートナーシップ・プロジェクト”（３ＧＰＰ）と名付けられた組織からの文書で説明されている。ｃｄｍａ２０００およびＵＭＢは、“第３世代パートナーシップ・プロジェクト２”（３ＧＰＰ２）と名付けられた組織からの文書で説明されている。明瞭にするために、技術のいくつかの観点を、ＬＴＥに対して以下で説明し、ＬＴＥの用語は、以下の記述の多くにおいて使用される。]
[0013] 図１は、ＬＴＥシステムであってもよい、ワイヤレス通信システム１００を示す。システム１００は、進化型ノードＢ（ｅＮＢ）および３ＧＰＰによって記述されている他のネットワークエンティティを含んでもよい。簡単にするために、２つのｅＮＢ１２０および１２２と、１つのモビリティマネジメントエンティティ（ＭＭＥ）／サービングゲートウェイ１３０とだけを図１中で示している。ｅＮＢは、ＵＥと通信する固定局であってもよく、ノードＢ、基地局、アクセスポイントなどとも呼ばれてもよい。各ｅＮＢは、特定の地理的エリアに対して通信カバレッジを提供してもよい。システム容量を向上させるために、ｅＮＢの全カバレッジエリアは、複数（例えば３つ）のより小さいエリアに区分化されてもよい。より小さい各エリアは、それぞれのｅＮＢサブシステムによってサーブされてもよい。３ＧＰＰにおいて、用語“セル”は、ｅＮＢの最も小さいカバレッジエリアおよび／または、このカバレッジエリアをサーブするｅＮＢサブシステムを指すことができる。ｅＮＢ１２０および１２２は、論理または物理インターフェースであってもよい、Ｘ２インターフェースを通して互いに通信してもよい。ｅＮＢ１２０および１２２はまた、Ｓ１インターフェースを通してＭＭＥ／サービングゲートウェイ１３０と通信してもよい。] 図１
[0014] サービングゲートウェイ１３０は、パケットデータや、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）や、ビデオや、メッセージングなどのようなデータサービスをサポートしてもよい。ＭＭＥ１３０は、ハンドオーバにおいて、ソースｅＮＢおよびターゲットｅＮＢ間のパスの切り換えを担当してもよい。ＭＭＥ／サービングゲートウェイ１３０は、コアおよび／またはデータネットワーク１４０（例えば、インターネット）に結合していてもよく、コア／データネットワーク１４０に結合する他のエンティティ（例えば、リモートサーバおよび端末）と通信してもよい。]
[0015] ＵＥ１１０は、ダウンリンクおよびアップリンクを通してｅＮＢ１２０および／または１２２と通信してもよい。ダウンリンク（すなわちフォワードリンク）は、ｅＮＢからＵＥへの通信リンクを指し、アップリンク（すなわちリバースリンク）は、ＵＥからｅＮＢへの通信リンクを指す。ＵＥ１１０はまた、移動局、端末、アクセス端末、加入者ユニット、局などと呼ばれてもよい。ＵＥ１１０は、セルラ電話機、パーソナルデジタルアシスタント（ＰＤＡ）、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレス電話機、ワイヤレスローカルループ（ＷＬＬ）局などであってもよい。]
[0016] 図２は、ＬＴＥにおけるユーザプレーンに対するプロトコルスタックの例２００を示す。ユーザプレーンは、サービングｅＮＢを通して、ＵＥ１１０およびサービングゲートウェイ１３０間のトラフィックデータを搬送する。サービングｅＮＢは、図１中のｅＮＢ１２０または１２２であってもよい。各エンティティは、別のエンティティとの通信のためのプロトコルスタックを維持する。各プロトコルスタックは通常、ネットワークレイヤ（レイヤ３またはＬ３）と、リンクレイヤ（レイヤ２またはＬ２）と、物理レイヤ（レイヤ１、Ｌ１またはＰＨＹ）とを含む。ＵＥおよびサービングゲートウェイは、ネットワークレイヤにおいてＩＰを使用してデータを交換してもよい。伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、リアルタイムトランスポートプロトコル（ＲＴＰ）、および／または他のプロトコル、に対する上位レイヤデータは、ＩＰパケット中でカプセル化されてもよく、ＩＰパケットは、サービングｅＮＢを通してＵＥおよびサービングゲートウェイ間で交換されてもよい。] 図１ 図２
[0017] リンクレイヤは一般に、ネットワーク／無線技術に依存する。ＬＴＥにおけるユーザプレーンに対して、ＵＥに対するリンクレイヤは、サービングｅＮＢにおいて終端される、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）と、無線リンク制御（ＲＬＣ）と、媒体アクセス制御（ＭＡＣ）とに対する３つのサブレイヤから構成される。ＵＥはさらに、物理レイヤにおいてＥ−ＵＴＲＡエアリンクインターフェースを通してサービングｅＮＢと通信する。サービングｅＮＢは、ＩＰと、リンクレイヤおよび物理レイヤに対する技術に依存するインターフェースとを通して、サービングゲートウェイと通信してもよい。ＰＤＣＰは、上位レイヤプロトコルヘッダの圧縮や、暗号化／解読や、セキュリティのための、データのインテグリティ保護などのような、さまざまな機能を実行してもよい。ＲＬＣは、（ｉ）送信機における、ＲＬＣサービスデータユニット（ＳＤＵ）のセグメント化および連結、ならびに自動リピートリクエスト（ＡＲＱ）によるエラー補正、（ｉｉ）受信機における、下位レイヤＳＤＵの重複検出、ＲＬＣ ＳＤＵの再順序付け、上位レイヤプロトコルデータユニット（ＰＤＵ）の順序通りの配信、のようなさまざまな機能を実行してもよい。ＬＴＥにおけるＰＤＣＰおよびＲＬＣによって実行される機能は、他の無線技術における同等のプロトコルによって提供されてもよい。例えば、ｃｄｍａ２０００におけるＩＰアダプテーションレイヤおよび無線リンクプロトコル（ＲＬＰ）は、それぞれＰＤＣＰおよびＲＬＣによって実行される機能と類似の機能を実行してもよい。]
[0018] ＰＤＣＰは、“進化型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）；パケットデータコンバージェンスプロトコル（ＰＤＣＰ）仕様”と題する３ＧＰＰ ＴＳ ３６．３２３において説明されている。ＲＬＣは、“進化型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）；無線リンク制御（ＲＬＣ）プロトコル仕様”と題する３ＧＰＰ ＴＳ ３６．３２２において説明されている。これらの文書は公に利用可能である。]
[0019] 図１を再度参照すると、ＵＥ１１０は初めに、ＭＭＥ／サービングゲートウェイ１３０とのデータ交換のためにｅＮＢと通信してもよい。ＵＥ１１０は移動体であってもよく、ｅＮＢ１２０からｅＮＢ１２２にハンドオーバされてもよい。ハンドオーバに対して、ｅＮＢ１２０は、ソースｅＮＢと呼ばれてもよく、ｅＮＢ１２２は、ターゲットｅＮＢと呼ばれてもよい。ハンドオーバ後、ＵＥ１１０は、ＭＭＥ／サービングゲートウェイ１３０とのデータ交換のためにｅＮＢ１２２と通信してもよい。ｅＮＢ１２０は、ハンドオーバ前の、ＵＥ１１０に対するサービングｅＮＢであってもよく、ｅＮＢ１２２は、ハンドオーバ後の、ＵＥ１１０に対するサービングｅＮＢであってもよい。] 図１
[0020] ここでの記述において、ハンドオーバまたはハンドオフは、１つのｅＮＢから別のｅＮＢへのハンドオーバだけでなく、同じｅＮＢの異なるセル間のハンドオーバも指してもよい。ハンドオーバは、システムまたはＵＥによって開始される。ＵＥは、順方向ハンドオーバ手続きにしたがってハンドオーバを開始してもよく、または、稼動休止を経験した後に、適切なｅＮＢとの無線接続を再確立してもよい。さらに、ハンドオーバは、システムにおけるユーザのモビリティをサポートするために、ロードバランシングを提供するために、無線接続の再設定を容易にするために、予知できないエラーのケースの取り扱いを容易にするために、などのために生じてもよい。システムはまた、上述の理由のいずれかに対してハンドオーバを開始してもよい。]
[0021] 図３は、ソースｅＮＢ１２０からターゲットｅＮＢ１２２へのＵＥ１１０のハンドオーバに対する例示的なコールフロー３００を示す。ソースｅＮＢは、ＵＥに対する測定手順を設定してもよく（ステップ１）、ＵＥは、測定報告をソースｅＮＢに送ってもよい（ステップ２）。ソースｅＮＢは、ＵＥをハンドオーバ（ＨＯ）することを決定してもよく（ステップ３）、ハンドオーバ要求メッセージをターゲットｅＮＢに発行してもよい（ステップ４）。ターゲットｅＮＢは、許可制御を実行してもよく、ＵＥのハンドオーバを受け入れてもよい（ステップ５）。ターゲットｅＮＢは、ハンドオーバ要求肯定応答（Ａｃｋ）メッセージをソースｅＮＢに戻してもよい（ステップ６）。ソースｅＮＢは次に、ハンドオーバコマンドメッセージをＵＥに送ってもよい（ステップ７）。] 図３
[0022] ハンドオーバに先立って、ソースｅＮＢは、サービングゲートウェイからＵＥに対するパケットを受信してもよく（ステップＡ）、パケットをＵＥに送ってもよい（ステップＢ）。ステップ７においてハンドオーバコマンドメッセージを送った後、ソースｅＮＢは、ＵＥに対するバッファに入れられているパケットを、ターゲットｅＮＢに転送してもよい（ステップＣおよびＤ）。転送されるパケットは、ＵＥに送られていないパケットだけでなく、移行中のパケット、例えば、送られたが、ＵＥによって無事に受信されていないパケットも含んでいてもよい。ターゲットｅＮＢは、ソースｅＮＢから受信したパケットをバッファに入れてもよい（ステップＥ）。]
[0023] ステップ７におけるハンドオーバコマンドメッセージを受信すると、ＵＥは、ソースｅＮＢから切り離されてもよく、ターゲットｅＮＢへの同期を実行して、アップリンクタイミングアドバンスの獲得を開始してもよい（ステップ８）。ターゲットｅＮＢは、ＵＥに対するリソース割り当ておよびタイミングアドバンス（ＴＡ）により応答する（ステップ９）。いったん、ＵＥがターゲットｅＮＢに無事にアクセスすると、ＵＥは、ハンドオーバ確認メッセージをターゲットｅＮＢに送って、ハンドオーバ手続きがＵＥに対して完了したことを示してもよい（ステップ１０）。]
[0024] ターゲットｅＮＢは、ハンドオーバ完了メッセージを送って、ＵＥがｅＮＢを変更していることをＭＭＥ／サービングゲートウェイに知らせてもよい（ステップ１１）。ＭＭＥ／サービングゲートウェイは、ＵＥに対するデータパスまたは接続を、ソースｅＮＢからターゲットｅＮＢに切り換えてもよい（ステップＧ）。ＭＭＥ／サービングゲートウェイはまた、ハンドオーバ完了ＡｃｋメッセージをターゲットｅＮＢに戻してもよい（ステップ１２）。ターゲットｅＮＢは、解放リソースメッセージをソースｅＮＢに送って、ＵＥのハンドオーバの成功を示してもよい（ステップ１３）。解放リソースメッセージを受信すると、ソースｅＮＢは、ＵＥに対するリソースを開放してもよい。]
[0025] ステップ１１におけるハンドオーバ完了メッセージを受信することに先立って、サービングゲートウェイは、ＵＥに対するパケットをソースｅＮＢに送ることを継続してもよい（ステップＦ）。ソースｅＮＢは、ＵＥに対するパケットをターゲットｅＮＢに転送することを継続してもよい（ステップＨ）。ステップ１１におけるハンドオーバ完了メッセージを受信した後、サービングゲートウェイは、ＵＥに対するパケットをターゲットｅＮＢに送ってもよい（ステップＩ）。ターゲットｅＮＢは、ソースｅＮＢから転送されたパケットと、サービングゲートウェイから受信したパケットとを、ＵＥに送ってもよい（ステップＪ）。]
[0026] 図３は、ソースｅＮＢからターゲットｅＮＢへのＵＥのハンドオーバに対する例示的なコールフローを示す。ＵＥのハンドオーバは、他のコールフローにより実行されてもよい。] 図３
[0027] 図４は、ハンドオーバの間の、データ送信およびデータ転送の例を示す。ハンドオーバに先立って、サービングゲートウェイは、Ｓ１インターフェースを通して、ＵＥに対するパケットをソースｅＮＢに送ってもよい（図３中のステップＡおよびＦ）。ソースｅＮＢは、ＰＤＣＰＳＤＵとしてパケットを受信してもよく、各ＰＤＣＰ ＳＤＵに対してＰＤＣＰシーケンス番号（ＳＮ）を割り当ててもよい。ここでの記述において、ＰＤＣＰ ＳＤＵ＃ｋは、ｋのＰＤＣＰ ＳＮを有するＰＤＣＰ ＳＤＵを表す。ソースｅＮＢは、各ＰＤＣＰ ＳＤＵを処理して、ＵＥに送ってもよい（図３中のステップＢ）。] 図３ 図４
[0028] ハンドオーバの間のいくつかの点において、ＵＥに対するデータパスは、ソースｅＮＢからターゲットｅＮＢに切り換えられてもよい（図３中のステップＧ）。この点以降、サービングゲートウェイは、Ｓ１インターフェースを通して、ＵＥに対する新しいパケットをターゲットｅＮＢに送ってもよい（図３中のステップＩ）。ターゲットｅＮＢは、ＰＤＣＰＳＤＵとしてパケットを受信してもよく、各ＰＤＣＰ ＳＤＵに対してＰＤＣＰ ＳＮを割り当ててもよい。ターゲットｅＮＢは、各ＰＤＣＰ ＳＤＵを処理して、ＵＥに送ってもよい（図３中のステップＪ）。] 図３
[0029] ハンドオーバの間、ソースｅＮＢは、（ｉ）まだＵＥに送られていないペンディングのＰＤＣＰＳＤＵ、および／または、（ｉｉ）ＵＥに送られているが、ＵＥによって正しくデコードされていない移行中のＰＤＣＰ ＳＤＵ、を有していてもよい。ソースｅＮＢは、Ｘ２インターフェースを通して、ペンディングおよび移行中のＰＤＣＰ ＳＤＵをターゲットｅＮＢに転送してもよい（図３中のステップＤおよびＨ）。ターゲットｅＮＢは、例えば、Ｘ２インターフェースのパケット交換の性質に起因して、転送パケットを順序が狂って受信するかもしれない。サービングゲートウェイは、新しいパケットをターゲットｅＮＢに順に送ってもよい。ターゲットｅＮＢはまた、例えば、Ｓ１インターフェースのパケット交換の性質に起因して、新しいパケットを順序が狂って受信するかもしれない。] 図３
[0030] 図４中で示した例において、ＰＤＣＰＳＤＵ＃１が最も早いＰＤＣＰ ＳＤＵであり、ＰＤＣＰ ＳＤＵ＃４が最後のＰＤＣＰ ＳＤＵであるように、ＰＤＣＰ ＳＤＵが順序付けられてもよい。ソースｅＮＢは、ＰＤＣＰ ＳＤＵ＃１ないし＃４をＵＥに順に送ってもよい。ＵＥは、ＰＤＣＰ ＳＤＵ＃１を正しくデコードし、ＰＤＣＰ ＳＤＵ＃２および＃３を誤ってデコードし、ＰＤＣＰ ＳＤＵ＃４を正しくデコードするかもしれない。ＰＤＣＰ ＳＤＵ＃４の早いＨＡＲＱターミネーションに起因して、ＵＥはＰＤＣＰ ＳＤＵ＃４を正しくデコードするが、ＰＤＣＰ ＳＤＵ＃２および＃３を正しくデコードしないかもしれない。ソースｅＮＢは、ＰＤＣＰ ＳＤＵ＃２および＃３をターゲットｅＮＢに転送してもよい。ターゲットｅＮＢは、ＰＤＣＰ ＳＤＵ＃２の前にＰＤＣＰ ＳＤＵ＃３を受信するかもしれない。サービングゲートウェイからの新しいパケットに先立って、ターゲットｅＮＢは、ＰＤＣＰ ＳＤＵ＃２および／またはＰＤＣＰ ＳＤＵ＃３をＵＥに送ってもよい。] 図４
[0031] 図５Ａは、送信エンティティにおけるＰＤＣＰＳＤＵの暗号化を示す。送信エンティティは、ダウンリンク送信に対してサービングｅＮＢであってもよく、または、アップリンク送信に対してＵＥであってもよい。ユニット５１０は、ＫＥＹや、ＣＯＵＮＴや、ＢＥＡＲＥＲや、ＤＩＲＥＣＴＩＯＮのようなパラメータ受け取ってもよい。ＫＥＹパラメータは、データを暗号化するために使用される暗号キーを含んでいてもよい。ＣＯＵＮＴパラメータは、暗号化アルゴリズムに対する時変入力として作動する暗号同期であってもよい。ＢＥＡＲＥＲパラメータは、暗号化されるデータの無線ベアラを示してもよい。ＤＩＲＥＣＴＩＯＮパラメータは、アップリンク送信に対して‘０’に、または、ダウンリンク送信に対して‘１’に設定されてもよいビットを含んでいてもよい。ユニット５１０は、すべてのパラメータに基づき、ＬＴＥによって規定される暗号化アルゴリズムにしたがって、キーストリームを発生させてもよい。排他的ＯＲゲート５１２は、ユニット５１０からのキーストリームビットと、ＰＤＣＰ ＳＤＵに対する入力データビットとののビットワイズなモジューロ−２加算を実行してもよく、ＰＤＣＰ ＳＤＵに対する暗号化されたデータビットを提供してもよい。] 図５Ａ
[0032] 図５Ｂは、受信エンティティにおける、ＰＤＣＰＳＤＵの解読を示す。受信エンティティは、ダウンリンク送信に対してＵＥであってもよく、または、アップリンク送信に対してサービングｅＮＢであってもよい。ユニット５５０は、ＫＥＹ、ＣＯＵＮＴ、ＢＥＡＲＥＲおよびＤＩＲＥＣＴＩＯＮのパラメータを受信してもよい。ユニット５５０は、すべてのパラメータに基づき、送信エンティティにおけるユニット５１０と同じ方法で、キーストリームを発生させてもよい。排他的ＯＲゲート５５２は、ユニット５５０からのキーストリームビットと、ＰＤＣＰ ＳＤＵに対する暗号化されたデータビットとのビットワイズなモジューロ−２加算を実行してもよく、ＰＤＣＰ ＳＤＵに対する解読されたデータビットを提供してもよい。] 図５Ｂ
[0033] 図６Ａは、ＬＴＥにおけるＣＯＵＮＴパラメータの設計を示す。ＣＯＵＮＴは、ＭビットのＨＦＮとＮビットのＰＤＣＰ ＳＮとで構成される３２ビット値である。ここで、ＭおよびＮは、設定可能な値であってもよい。ＨＦＮは、ＣＯＵＮＴのＭ個の最上位ビット（ＭＳＢ）を占有し、ＰＤＣＰ ＳＮは、ＣＯＵＮＴのＮ個の最下位ビット（ＬＳＢ）を占有する。１つの構成において、３２ビットのＣＯＵＮＴは、２０ビットのＨＦＮと、１２ビットのＰＤＣＰ ＳＮとで構成される。別の構成において、３２ビットのＣＯＵＮＴは、２５ビットのＨＦＮと、７ビットのＰＤＣＰ ＳＮとで構成される。両方の構成に対して、ＰＤＣＰ ＳＮは、各ＰＤＣＰＳＤＵとともに無線で送られる。ＨＦＮは、オーバーヘッドを低減させるために、無線で送られない。] 図６Ａ
[0034] 図６Ｂは、ＰＤＣＰ ＳＮ空間を示し、ＰＤＣＰ ＳＮ空間は、０ないしＫの範囲をカバーしてもよく、Ｋ＝２N−１である。例えば、Ｋは、７ビットのＰＤＣＰ ＳＮに対して１２７に等しくてもよく、または、１２ビットのＰＤＣＰ ＳＮに対して４０９５に等しくてもよい。ＰＤＣＰＳＤＵは、０ないしＫの範囲内であってもよい、ｋのＰＤＣＰ ＳＮを有してもよい。ＰＤＣＰ ＳＮは、それがＫの最大値に到達するまで新しい各ＰＤＣＰ ＳＤＵに対してインクリメントされてもよく、次に、０にラップアラウンドしてもよい。] 図６Ｂ
[0035] ｋのＰＤＣＰ ＳＮに対して、ＰＤＣＰ ＳＮ空間の一部は、ｋよりも“遅い”と考えてもよく、ＰＤＣＰ ＳＮ空間の残りの部分は、ｋよりも“早い”と考えてもよい。例えば、図６Ｂ中で示すように、ｋ＋１ないしＬのＰＤＣＰ ＳＮは、ｋのＰＤＣＰ ＳＮよりも遅いものであると考えてもよく、Ｌ＋１ないしｋ−１のＰＤＣＰ ＳＮは、ｋのＰＤＣＰ ＳＮよりも早いものであると考えてもよい。Ｌは、Ｌ＝（ｋ＋Ｋ／２）ｍｏｄ Ｋとして規定されてもよく、そのため、ＰＤＣＰ ＳＮ空間の半分がｋよりも遅く、ＰＤＣＰ ＳＮ空間の他の半分がｋよりも早い。Ｌはまた、他の方法で規定してもよい。] 図６Ｂ
[0036] 図６Ｂ中でさらに示すように、０ないしｋ−１のＰＤＣＰ ＳＮは、ｋよりも“小さい”と考えてもよく、ｋ＋１ないしＫのＰＤＣＰ ＳＮは、ｋよりも“大きい”と考えてもよい。] 図６Ｂ
[0037] ＵＥは、ｅＮＢ１２０にアクセスしてもよく、ｅＮＢとの通信に対して無線ベアラを確立してもよい。無線ベアラが確立されるとき、ＵＥおよびｅＮＢはそれぞれ、ＣＯＵＮＴをゼロにリセットしてもよい。ｅＮＢは、新しいＰＤＣＰＳＤＵがサービングゲートウェイから受信されるたびにＰＤＣＰ ＳＮをインクリメントしてもよく、Ｋの最大値に到達後にＰＤＣＰ ＳＮがゼロにラップアラウンドするたびにＨＦＮをインクリメントしてもよい。ｅＮＢは、各ＰＤＣＰ ＳＤＵと、そのＰＤＣＰ ＳＮとをＵＥに送ってもよい。ＵＥは、ｅＮＢからＰＤＣＰ ＳＤＵを受信してもよく、ＰＤＣＰ ＳＮに基づいてＨＦＮを更新してもよい。]
[0038] ＵＥは、ソースｅＮＢ１２０からターゲットｅＮＢ１２２にハンドオーバされてもよい。ハンドオーバに対して、ソースｅＮＢは、現在のＨＦＮおよび現在のＰＤＣＰ ＳＮのような関連状態情報をターゲットｅＮＢに送ってもよい。ターゲットｅＮＢは、ソースｅＮＢから受信した現在のＰＤＣＰ ＳＮおよびＨＦＮから始め、ＰＤＣＰ ＳＮを、サービングゲートウェイから受信した新しいＰＤＣＰＳＤＵに割り当ててもよい。ＵＥは、ハンドオーバを通してＣＯＵＮＴを維持してもよく、ターゲットｅＮＢから受信したＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮに基づいて、ＨＦＮを更新してもよい。]
[0039] ＬＴＥにおけるＰＤＣＰ仕様は、増加のＰＤＣＰ ＳＮを有するＰＤＣＰＳＤＵが送信エンティティにおいて下位レイヤにパスされるという仮定の下に書かれている。受信エンティティは、下位レイヤが適切な順序でＰＤＣＰ ＳＤＵを引き渡すことを仮定してもよい。したがって、受信エンティティは、新たに受信したＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮが、最後に受信したＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮよりも小さいときはいつでもＨＦＮをインクリメントするかもしれない。]
[0040] 上述した仮定に基づく、ダウンリンク上でのデータ送信に対する従来の処理スキームは、次のようであってもよい。サービングｅＮＢが、サービングゲートウェイから受信した各ＰＤＣＰＳＤＵに対してＰＤＣＰ ＳＮを割り当ててもよい。ｅＮＢは、各ＰＤＣＰ ＳＤＵ後にＰＤＣＰ ＳＮをインクリメントしてもよく、ＰＤＣＰ ＳＮがゼロにラップアラウンドするたびにＨＦＮをインクリメントしてもよい。図５Ａ中で示したように、ｅＮＢは、ｅＮＢによって維持されるＨＦＮと、各ＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮとによって形成されるＣＯＵＮＴにより、各ＰＤＣＰ ＳＤＵを暗号化してもよい。ｅＮＢは、適切な順序で各ＰＤＣＰ ＳＤＵをＵＥに送信してもよい。ＵＥは、適当な順序で、ｅＮＢからＰＤＣＰ ＳＤＵを受信してもよい。ＵＥは、最後のＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮよりも小さいＰＤＣＰ ＳＮを有するＰＤＣＰ ＳＤＵを受信するたびに、ＨＦＮをインクリメントしてもよい。ＵＥは、ＵＥによって維持されるＨＦＮと、受信した各ＰＤＣＰ ＳＤＵから取得されるＰＤＣＰ ＳＮとによって形成されるＣＯＵＮＴにより、受信した各ＰＤＣＰ ＳＤＵを解読してもよい。] 図５Ａ
[0041] 上述した従来の処理スキームは、ソースｅＮＢからターゲットｅＮＢへのＵＥのハンドオーバの間にエラーを結果として生じるかもしれない。ハンドオーバにおいて、ソースｅＮＢは、Ｘ２（またはＳ１）インターフェースを通してＰＤＣＰＳＤＵをターゲットｅＮＢに転送してもよい。Ｘ２（またはＳ１）インターフェースは、回路交換インターフェースでないことから、例えば、図４中で示すように、転送されるＰＤＣＰ ＳＤＵは、ターゲットｅＮＢに順序が狂って到着するかもしれない。転送された各ＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるときに、ターゲットｅＮＢがそれを処理する場合、ターゲットｅＮＢにおいて順序が狂ってＰＤＣＰ ＳＤＵを受信することは、ＵＥにおける解読のエラーおよび／またはＨＦＮ同期損失を結果として生じさせるかもしれない。] 図４
[0042] 図４中で示した例に対して、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰＳＤＵ＃３を受信してもよく、ＨＦＮと、３のＰＤＣＰ ＳＮとによって形成されるＣＯＵＮＴにより、このＰＤＣＰ ＳＤＵを暗号化してもよい。このＣＯＵＮＴは、（ＨＦＮ｜３）として表わしてもよい。ターゲットｅＮＢは、ＵＥに対する送信のために、暗号化されたＰＤＣＰ ＳＤＵ＃３を下位レイヤにパスしてもよい。その後、ターゲットｅＮＢは、ソースｅＮＢから順序が狂っているＰＤＣＰ ＳＤＵ＃２を受信してもよい。] 図４
[0043] ターゲットｅＮＢは、（ＨＦＮ｜２）によってＰＤＣＰＳＤＵ＃２を暗号化してもよく、（ＨＦＮ｜２）は、このＰＤＣＰ ＳＤＵに対して正しいＣＯＵＮＴである。しかしながら、上述した従来の処理スキームに対して、ＵＥがＰＤＣＰ ＳＤＵ＃３を受信した後にＰＤＣＰ ＳＤＵ＃２を受信するとき、ＵＥはそのＨＦＮをインクリメントするかもしれない。ＵＥは次に、（ＨＦＮ＋１｜２）によりＰＤＣＰ ＳＤＵ＃２を解読するかもしれず、ターゲットｅＮＢは（ＨＦＮ｜２）を使用していることから、誤ってＰＤＣＰ ＳＤＵを解読するだろう。さらに、ターゲットｅＮＢは暗号化するためにＨＦＮの使用を継続する一方で、ＵＥは後続のＰＤＣＰ ＳＤＵを解読するのにＨＦＮ＋１を使用することから、ＵＥは、ＨＦＮ同期から外れるだろう。したがって、後続のＰＤＣＰ ＳＤＵは、ＵＥによって誤って解読されるかもしれない。]
[0044] ＵＥは、重複−廃棄窓を維持して、ＨＦＮ同期から外れることを回避してもよい。窓の始まりは、上位レイヤに引き渡された最後のＰＤＣＰＳＤＵに配置されてもよく、窓の終わりは、上位レイヤにまだ引き渡されていない最新のＰＤＣＰ ＳＤＵに配置されてもよい。ＵＥは、重複−廃棄窓を使用して、ＰＤＣＰ ＳＤＵを処理して上位レイヤに引き渡すか、または、ＰＤＣＰ ＳＤＵを廃棄するかを決定してもよい。]
[0045] 図４中で示した例に対して、ＵＥは、ＰＤＣＰＳＤＵ＃１および＃４を正しくデコードするかもしれないが、ＰＤＣＰ ＳＤＵ＃２および＃３を正しくデコードしないかもしれない。ＵＥはＰＤＣＰ ＳＤＵ＃１を上位レイヤに引渡してもよく、ＰＤＣＰ ＳＤＵ＃４をバッファに入れてもよい。ＵＥは次に、ターゲットｅＮＢからＰＤＣＰ ＳＤＵ＃３を受信してもよく、このＰＤＣＰ ＳＤＵを正しくデコードするかもしれない。ＵＥは、ＰＤＣＰ ＳＤＵがターゲットｅＮＢによって順に送られることを仮定してもよく、ＰＤＣＰ ＳＤＵ＃２が失われていることを仮定してもよい。ＵＥは次に、ＰＤＣＰ ＳＤＵ＃３および＃４を上位レイヤに引渡してもよく、重複−廃棄窓の始まりをＰＤＣＰ ＳＤＵ＃４に移動してもよい。その後、ＵＥは、ターゲットｅＮＢからＰＤＣＰ ＳＤＵ＃２を受信するかもしれない。ＵＥは、このＰＤＣＰ ＳＤＵが重複−廃棄窓から外れていることを認識してもよく、ＰＤＣＰ ＳＤＵを廃棄してもよい。ＵＥは、ＨＦＮをインクリメントする代わりに、ＨＦＮを維持してもよい。このＵＥ処理スキームは、ＨＦＮ同期の損失を回避するかもしれない。しかしながら、ＵＥが廃棄するであろう、順序が狂っているＰＤＣＰＳＤＵを送ることによって、無線リソースが浪費される。] 図４
[0046] さまざまな処理スキームを使用して、順序が狂っているパケットを取り扱い、ＵＥにおけるＨＦＮ同期損失を回避してもよい。ターゲットｅＮＢが、ソースｅＮＢから転送された、ＰＤＣＰＳＤＵを順序が狂って受信するハンドオーバの間に、これらの処理スキームを使用してもよい。]
[0047] 第１の処理スキームにおいて、ターゲットｅＮＢは、それがＵＥに順に送ることができないＰＤＣＰＳＤＵを廃棄してもよい。ターゲットｅＮＢは、ＰＤＣＰ ＳＤＵが受信されるとき、それらを処理して送ってもよく、これらのＰＤＣＰ ＳＤＵを再順序付けすることを試みない。代わりに、ＵＥに送られているＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮよりも早いＰＤＣＰ ＳＮを有する、転送されたＰＤＣＰ ＳＤＵをターゲットｅＮＢが受信する場合、ターゲットｅＮＢは転送されたＰＤＣＰ ＳＤＵを廃棄し、それをＵＥに送らない。ターゲットｅＮＢは、ＵＥに送られた最後のＰＤＣＰ ＳＮのＰＤＣＰ ＳＮに対してポインタを維持してもよい。ターゲットｅＮＢは、転送されたＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮを、このポインタと比較して、ＰＤＣＰ ＳＤＵを順にＵＥに送ることができるかどうかを決定してもよい。]
[0048] 図４中で示した例に対して、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰＳＤＵ＃３を受信し、（ＨＦＮ｜３）によりこのＰＤＣＰ ＳＤＵを暗号化し、暗号化されたＰＤＣＰ ＳＤＵをＵＥに送ってもよい。ターゲットｅＮＢは、ポインタを３に設定してもよい。その後、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰ ＳＤＵ＃２を受信してもよく、２のＰＤＣＰ ＳＮをポインタと比較してもよい。２のＰＤＣＰ ＳＮが、送信されたＰＤＣＰ ＳＤＵの３のＰＤＣＰ ＳＮよりも早いことから、ターゲットｅＮＢは、このＰＤＣＰ ＳＤＵを廃棄してもよい。] 図４
[0049] 第１の処理スキームは、ターゲットｅＮＢの動作を簡単にすることができる。ＵＥが上述した重複−廃棄窓を使用して廃棄するであろう、順序が狂っているＰＤＣＰＳＤＵを、ターゲットｅＮＢが送らないことから、この処理スキームはまた、無線リソースを節約することができる。]
[0050] 第２の処理スキームにおいて、ターゲットｅＮＢは、短い時間の期間またはＰＤＣＰ ＳＮの小さい範囲に対して、転送されたＰＤＣＰＳＤＵの再順序付けを実行してもよい。この短い時間期間、または小さいＰＤＣＰ ＳＮの範囲は、再順序付け窓と呼ばれてもよい。]
[0051] 時間ベースの再順序付け窓に対して、ターゲットｅＮＢは、タイマを使用して、時間の経過を追ってもよく、ソースｅＮＢから最初の転送ＰＤＣＰＳＤＵを受信したときにタイマを開始してもよい。ターゲットｅＮＢは、タイマがアクティブである間に、ソースｅＮＢから順序が狂って受信した、転送されたすべてのＰＤＣＰ ＳＤＵをバッファに入れてもよい。タイマが満了するとき、ターゲットｅＮＢは、バッファに入れられているすべてのＰＤＣＰ ＳＤＵを再順序付けしてもよく、再順序付けされた各ＰＤＣＰ ＳＤＵを暗号化して、ＵＥに送ってもよい。再順序付け窓を使用して、ソースｅＮＢから最初に転送されたＰＤＣＰ ＳＤＵよりも早いＰＤＣＰ ＳＤＵを受信してもよい。]
[0052] 図４中で示した例に対して、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰＳＤＵ＃３を受信し、このＰＤＣＰ ＳＤＵをバッファに入れ、タイマを開始してもよい。その後、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰ ＳＤＵ＃２を受信してもよく、このＰＤＣＰ ＳＤＵもバッファに入れてもよい。タイマが満了するとき、ターゲットｅＮＢは、ＰＤＣＰ ＳＤＵ＃２および＃３を再順序付けしてもよい。ターゲットｅＮＢは次に、ＰＤＣＰ ＳＤＵ＃２を処理して送ってもよく、次に、ＰＤＣＰ ＳＤＵ＃３を処理して送ってもよい。代替として、ＰＤＣＰ ＳＤＵ＃２を受信すると、タイマが満了するのを待つ代わりに、ターゲットｅＮＢは、ＰＤＣＰ ＳＤＵ＃２および＃３を再順序付けし、暗号化して、ＵＥに送ってもよい。ターゲットｅＮＢによる処理は、ターゲットｅＮＢに利用可能な状態情報に依存してもよい。いずれにせよ、ＵＥは、ターゲットｅＮＢから、順にＰＤＣＰ ＳＤＵ＃２および＃３を受信することができる。] 図４
[0053] １つの設計において、ターゲットｅＮＢは、ソースｅＮＢから最初に転送されたＰＤＣＰＳＤＵだけに対してタイマを開始してもよい。ターゲットｅＮＢは、タイマが満了になった後に、第１の処理スキームと同じ方法で動作してもよい。この設計において、その後、ターゲットｅＮＢが、送信されているＰＤＣＰ ＳＤＵよりも早い、転送されたＰＤＣＰ ＳＤＵを受信した場合、ターゲットｅＮＢは、転送されたＰＤＣＰ ＳＤＵを単に廃棄してもよい。図４中で示した例に対して、ターゲットｅＮＢが、タイマの満了後にＰＤＣＰ ＳＤＵ＃２を受信した場合、ターゲットｅＮＢは、このＰＤＣＰ ＳＤＵを廃棄してもよい。] 図４
[0054] 別の設計において、ターゲットｅＮＢは、最初に転送されたＰＤＣＰＳＤＵに対して、また、非連続のＰＤＣＰ ＳＮを有する、転送されたＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるときに、タイマを開始してもよい。例えば、ターゲットｅＮＢは、タイマの満了後にＰＤＣＰ ＳＤＵ＃２および＃３を送ってもよく、その後、ソースｅＮＢからＰＤＣＰ ＳＤＵ＃６を受信してもよい。ターゲットｅＮＢは次にタイマを開始して、ソースｅＮＢからのＰＤＣＰ ＳＤＵ＃５を待ってもよい。]
[0055] ＰＤＣＰ ＳＮベースの再順序付け窓に対して、ターゲットｅＮＢは、窓の終わりを、ＵＥに送られた最後のＰＤＣＰＳＤＵに設定してもよい。再順序付け窓は、予め定められている数のＰＤＣＰ ＳＮまたは、すべてのペンディングおよび移行中のＰＤＣＰ ＳＤＵにわたってもよい。ターゲットｅＮＢは、より後のＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるたびに、再順序付け窓を進めてもよい。ターゲットｅＮＢは、最順序付け窓の開始においてＰＤＣＰ ＳＤＵを処理して送ってもよい。]
[0056] 図４中で示した例に対して、再順序付け窓は、ＰＤＣＰＳＤＵ＃２および＃３をカバーしてもよい。ターゲットｅＮＢがソースｅＮＢからＰＤＣＰ ＳＤＵ＃２を受信した場合、ターゲットｅＮＢは、このＰＤＣＰ ＳＤＵを処理して送って、窓を進めてもよい。ターゲットｅＮＢがソースｅＮＢからＰＤＣＰ ＳＤＵ＃３を受信した場合、ターゲットｅＮＢは、窓を維持して、ＰＤＣＰ ＳＤＵ＃２を待ってもよい。ターゲットｅＮＢがソースｅＮＢからＰＤＣＰ ＳＤＵ＃５を受信した場合、ＰＤＣＰ ＳＤＵ＃２を受信する可能性が低減されることから、ターゲットｅＮＢは、窓を進めてもよい。] 図４
[0057] 第２の処理スキームに対して、再順序付け窓の継続時間は、待ち時間およびデータ損失間のトレードオフに基づいて選択してもよい。より幅の広い再順序付け窓は、ソースｅＮＢから順序が狂って受信した、より多くのＰＤＣＰＳＤＵをＵＥに送ることができることを保証するかもしれないが、ＰＤＣＰ ＳＤＵをＵＥに送る際に、より長い遅延を結果として生じるかもしれない。逆に、より短い再順序付け窓は、ＰＤＣＰ ＳＤＵを送る際により短い遅延を結果として生じるかもしれないが、より多くのＰＤＣＰ ＳＤＵが廃棄されることを結果として生じるかもしれない。]
[0058] 第３の処理スキームにおいて、ターゲットｅＮＢは、ＨＦＮ同期損失を回避するために、ＵＥと同じ方法でＨＦＮを更新してもよい。上述した従来の処理スキームに対して、ＵＥは、ＰＤＣＰＳＤＵが順に送られることを仮定してもよく、より小さいＰＤＣＰ ＳＮを有する、転送されたＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるたびにＨＦＮをインクリメントしてもよい。ターゲットｅＮＢもまた、より小さいＰＤＣＰ ＳＮを有する、転送されたＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるたびにＨＦＮをインクリメントしてもよい。]
[0059] 第３の処理スキームに対して、ターゲットｅＮＢは、ソースｅＮＢから受信した、転送された各ＰＤＣＰＳＤＵを処理（例えば、暗号化）してもよく、ＰＤＣＰ ＳＤＵをＵＥに送ってもよい。転送された各ＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるとき、ターゲットｅＮＢにおいてＰＤＣＰ ＳＤＵをバッファに入れることなく、ターゲットｅＮＢは、転送された各ＰＤＣＰ ＳＤＵを処理して送ってもよい。より小さいＰＤＣＰ ＳＮを有する、転送されたＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるたびに、ターゲットｅＮＢはＨＦＮをインクリメントしてもよい。ターゲットｅＮＢは次に、更新されたＨＦＮにより、転送されたＰＤＣＰ ＳＤＵを暗号化してもよい。]
[0060] 図４中で示した例に対して、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰＳＤＵ＃３を受信し、（ＨＦＮ｜３）によりこのＰＤＣＰ ＳＤＵを暗号化して、暗号化されたＰＤＣＰ ＳＤＵをＵＥに送ってもよい。その後、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰ ＳＤＵ＃２を受信してもよい。ターゲットｅＮＢは、より小さいＰＤＣＰ ＳＮを受信したことに応答して、かつ、ＵＥがそのＨＦＮをインクリメントすることを予期して、ＨＦＮをインクリメントしてもよい。ターゲットｅＮＢは次に、（ＨＦＮ＋１｜２）により、ＰＤＣＰ ＳＤＵ＃２を暗号化して、暗号化されたＰＤＣＰ ＳＤＵをＵＥに送ってもよい。ＵＥは、暗号化されたＰＤＣＰ ＳＤＵ＃２を受信することに応答して、そのＨＦＮをインクリメントしてもよく、（ＨＦＮ＋１｜２）により、このＰＤＣＰ ＳＤＵを解読してもよい。たとえ、ＰＤＣＰ ＳＤＵ＃２が順序が狂って送られたとしても、ターゲットｅＮＢがＵＥと同じ方法でＨＦＮを更新することから、ＵＥは、ＰＤＣＰ ＳＤＵ＃２を正しく解読できる。順序が狂っている、解読されたＰＤＣＰ ＳＤＵ＃２が、（ＨＦＮ＋１｜２）のＣＯＵＮＴを有するのに対して、解読されたＰＤＣＰ ＳＤＵ＃３は（ＨＦＮ｜３）のＣＯＵＮＴを有することから、ＵＥは、解読されたＰＤＣＰ ＳＤＵ＃２を上位レイヤに引き渡してもよい。] 図４
[0061] 順序が狂っているＰＤＣＰＳＤＵを廃棄する代わりに、ＵＥがこれらのＰＤＣＰ ＳＤＵを上位レイヤに引き渡すことが望まれるかもしれない。上位レイヤは、データを再順序付けして、エンドアプリケーションに対して順にデータを提供できるプロトコル（例えば、ＴＣＰまたはＲＴＰ）を利用してもよい。さらに、順序が狂っているＰＤＣＰ ＳＤＵは、まれに発生するかもしれない。ＨＦＮの同期が保たれている限り、順序が狂っているＰＤＣＰ ＳＤＵを上位レイヤに引き渡すことが許容できるかもしれない。]
[0062] 第４の処理スキームにおいて、ターゲットｅＮＢは、ＨＦＮ同期損失を回避するために、必要に応じて、新しいＰＤＣＰ ＳＮで、転送されたＰＤＣＰＳＤＵを再割り当てしてもよい。この処理スキームに対して、転送された各ＰＤＣＰ ＳＤＵがソースｅＮＢから受信されるとき、ＰＤＣＰ ＳＤＵをバッファに入れることなく、ターゲットｅＮＢは、転送された各ＰＤＣＰ ＳＤＵを処理して送ってもよい。ターゲットｅＮＢが、ＵＥにすでに送信されているＰＤＣＰ ＳＤＵよりも早い、転送されたＰＤＣＰ ＳＤＵを受信した場合、ターゲットｅＮＢは、送信されているＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮよりも後の、新しいＰＤＣＰ ＳＮで、このＰＤＣＰ ＳＤＵを再割り当てしてもよい。]
[0063] 図４中で示した例に対して、４のＰＤＣＰ ＳＮがソースｅＮＢによって使用された最後のＰＤＣＰ ＳＮであったことを示す状態情報を、ターゲットｅＮＢは受信してもよい。ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰＳＤＵ＃３を受信し、（ＨＦＮ｜３）によりこのＰＤＣＰ ＳＤＵを暗号化し、暗号化されたＰＤＣＰ ＳＤＵをＵＥに送ってもよい。その後、ターゲットｅＮＢは、ソースｅＮＢからＰＤＣＰ ＳＤＵ＃２を受信してもよい。ターゲットｅＮＢは、５のＰＤＣＰ ＳＮで、このＰＤＣＰ ＳＤＵを再割り当てし、（ＨＦＮ｜５）によりこのＰＤＣＰ ＳＤＵを暗号化して、暗号化されたＰＤＣＰ ＳＤＵをＵＥに送ってもよい。その後、ターゲットｅＮＢがソースｅＮＢからＰＤＣＰ ＳＤＵ＃５を受信する場合、ターゲットｅＮＢは、６のＰＤＣＰ ＳＮで、このＰＤＣＰ ＳＤＵに再割り当てし、（ＨＦＮ｜６）によりＰＤＣＰ ＳＤＵを暗号化し、暗号化されたＰＤＣＰ ＳＤＵをＵＥに送ってもよい。したがって、ターゲットｅＮＢは、同じ方法でソースｅＮＢからの、転送された各ＰＤＣＰ ＳＤＵを再割り当てしてもよく、ＰＤＣＰ ＳＤＵを処理してＵＥに送ってもよい。] 図４
[0064] ターゲットｅＮＢは、ソースｅＮＢから順序が狂って受信される、転送されたＰＤＣＰＳＤＵに対してＰＤＣＰ ＳＮを再割り当てしてもよい。ＰＤＣＰ ＳＮのこの再割り当てにより、ＵＥは、ＨＦＮ同期を維持しながらＰＤＣＰ ＳＤＵを正しく解読することが可能になる。ＵＥは、順序が狂っているＰＤＣＰ ＳＤＵを上位レイヤに引き渡してもよく、このことは、上述したように、許容でき、または望まれるかもしれない。ターゲットｅＮＢは、サービングゲートウェイから受信した新しいパケットに対して、連続的に増加するＰＤＣＰ ＳＮを割り当ててもよい。]
[0065] 上述した４つの処理スキームは、ＨＦＮ同期損失を回避するかもしれない。ターゲットｅＮＢは、ソースｅＮＢから転送されたＰＤＣＰＳＤＵを受信してもよく、上述した４つの処理スキームのうちのいずれか１つを使用して、これらのＰＤＣＰ ＳＤＵを送ってもよい。４つのすべての処理スキームは、ＵＥが各ＰＤＣＰ ＳＤＵを正しく解読して、ターゲットｅＮＢとのＨＦＮ同期を維持することを可能にする。第１および第２の処理スキームは、ＵＥが上位レイヤに対して順にＰＤＣＰ ＳＤＵを引き渡すことを可能にしてもよい。第３および第４の処理スキームは、ＵＥにおいてＰＤＣＰ ＳＤＵが順序が狂って上位レイヤに引き渡されることを結果として生じるかもしれないが、このことは許容できるかもしれない。ＨＦＮ同期は、他の処理スキームにより達成してもよい。]
[0066] 明瞭にするために、処理スキームを、ＬＴＥにおけるＰＤＣＰＳＤＵに対して記述している。一般に、これらの処理スキームは、プロトコルスタック中の任意のレイヤにおけるパケットに対して、および、任意のプロトコルに対して使用してもよい。さらに、明瞭にするために、処理スキームは、ソースｅＮＢからターゲットｅＮＢへのＵＥのハンドオーバに対して記述している。これらの処理スキームはまた、サービングゲートウェイからサービングｅＮＢに送られるパケットに対して使用してもよい。パケットは、例えば、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）によって、シーケンス番号が割り当てられてもよい。サービングｅＮＢは、別のｅＮＢから転送されたＰＤＣＰ ＳＤＵと同じ方法で、サービングゲートウェイからのパケットを処理してもよい。]
[0067] 図７は、ワイヤレス通信システムにおいてパケットを送るためのプロセス７００の設計を示す。プロセス７００は、送信機によって実行してもよく、送信機は、ダウンリンク上でのデータ送信に対して基地局／ｅＮＢであってもよく、または、アップリンク上でのデータ送信に対してＵＥであってもよい。パケットのシーケンスが、例えば、パケット交換インターフェースを通して、第２のエンティティにおいて、第１のエンティティから受信される（ブロック７１２）。シーケンス中の各パケットを第３のエンティティに順に送ることができるかどうかを決定してもよい（ブロック７１４）。順に送ることができる各パケットを第３のエンティティに送ってもよい（ブロック７１６）。順に送ることができない各パケットを廃棄してもよい（ブロック７１８）。パケットが第１のエンティティから受信されるとき、第２のエンティティにおいてパケットをバッファに入れることなく、シーケンス中の各パケットを、処理して送るか、または、廃棄してもよい。] 図７
[0068] １つの設計において、第１のエンティティはソース基地局／ｅＮＢであってもよく、第２のエンティティはターゲット基地局／ｅＮＢであってもよく、第３のエンティティはＵＥであってもよい。ブロック７１２ないしブロック７１８は、ソース基地局からターゲット基地局へのＵＥのハンドオーバの間に、ターゲット基地局によって実行してもよい。別の設計において、第１のエンティティはサービングゲートウェイであってもよく、第２のエンティティは基地局であってもよく、第３のエンティティはＵＥであってもよい。パケットは、ＰＤＣＰＳＤＵまたは他の何らかのタイプのパケットを含んでいてもよい。]
[0069] ブロック７１２の１つの設計において、第３のパケットに送られた最後のパケットのシーケンス番号に対して、ポインタを維持してもよい。パケットを順に送ることができるかどうかは、そのパケットのシーケンス番号とポインタとに基づいて決定してもよい。第３のエンティティにすでに送られているパケットのシーケンス番号よりも早いシーケンス番号をパケットが有する場合、パケットを順に送ることができない。]
[0070] 図８は、ワイヤレス通信システムにおいてパケットを送る装置８００の設計を示す。装置８００は、第２のエンティティにおける、第１のエンティティからパケットのシーケンスを受信するモジュール８１２と、シーケンス中の各パケットを第３のエンティティに順に送ることができるかどうかを決定するモジュール８１４と、順に送ることができる各パケットを第３のエンティティに送るモジュール８１６と、順に送ることができない各パケットを廃棄するモジュール８１８とを含む。] 図８
[0071] 図９は、ワイヤレス通信システムにおいてパケットを送るためのプロセス９００の設計を示す。パケットのシーケンスが、例えば、パケット交換インターフェースを通して、第２のエンティティにおいて、第１のエンティティから受信されてもよい（ブロック９１２）。シーケンス中のパケットを再順序付けしてもよい（ブロック９１４）。再順序付けされたパケットを、第２のエンティティから第３のエンティティに送ってもよい（ブロック９１６）。] 図９
[0072] １つの設計において、第１のエンティティはソース基地局であってもよく、第２のエンティティはターゲット基地局であってもよく、第３のエンティティはＵＥであってもよい。ブロック９１２ないし９１６は、ソース基地局からターゲット基地局へのＵＥのハンドオーバの間に、ターゲット基地局によって実行してもよい。別の設計において、第１のエンティティはサービングゲートウェイであってもよく、第２のエンティティは基地局であってもよく、第３のエンティティはＵＥであってもよい。パケットは、ＰＤＣＰＳＤＵまたは他の何らかのタイプのパケットを含んでいてもよい。]
[0073] １つの設計において、パケットのシーケンスは、再順序付け窓によって決定される時間期間の間に、第２のエンティティによって受信されてもよい。ブロック９１４の１つの設計において、第１のエンティティからシーケンス中の最初のパケットを受信することに応答して、タイマを開始してもよい。最初のパケットが順に受信されない場合、最初のパケットをバッファに入れてもよい。タイマの満了前に第１のエンティティから順に受信されなかった後続のパケットもまた、バッファに入れてもよい。バッファに入れられているパケットを再順序付けして、タイマの満了後に送ってもよい。タイマの満了後に第１のエンティティから受信した各パケットは、第２のエンティティにおいてバッファに入れることなく処理して送ってもよい。]
[0074] 図１０は、ワイヤレス通信システムにおいてパケットを送る装置１０００の設計を示す。装置１０００は、第２のエンティティにおける、第１のエンティティからパケットのシーケンスを受信するモジュール１０１２と、シーケンス中のパケットを再順序付けするモジュール１０１４と、第２のエンティティから第３のエンティティに、再順序付けされたパケットを送るモジュール１０１６とを含む。] 図１０
[0075] 図１１は、ワイヤレス通信システムにおいてパケットを送るためのプロセス１１００の設計を示す。第１のシーケンス番号を有する第１のパケットが受信されてもよく（ブロック１１１２）、受信エンティティへの送信のために処理されてもよい（ブロック１１１４）。第１のシーケンス番号よりも早い第２のシーケンス番号を有する第２のパケットが受信されてもよい（ブロック１１１６）。第２のパケットは、第１のパケットに対して順序が狂って受信されるかもしれない。第２のパケットは、それが受信エンティティへの送信のために第１のパケットよりも後であるかのように処理されてもよい（ブロック１１１８）。第１および第２のパケットは、これらのパケットをバッファに入れることなく、各パケットが受信されるときに処理されてもよい。] 図１１
[0076] 受信エンティティはＵＥであってもよい。１つの設計において、第１および第２のパケットは、ソース基地局からターゲット基地局へのＵＥのハンドオーバの間にソース基地局によりターゲット基地局に転送されてもよい。別の設計において、第１および第２のパケットは、サービングゲートウェイから基地局により受信されてもよい。]
[0077] ブロック１１１４の１つの設計において、第１のパケットは、ＨＦＮおよび第１のシーケンス番号を含む第１のカウントにより暗号化されてもよい。ブロック１１１８の１つの設計において、ＨＦＮは、順序が狂って第２のパケットを受信することに応答してインクリメントされてもよい。第２のパケットは、インクリメントされたＨＦＮおよび第２のシーケンス番号を含む第２のカウントにより暗号化されてもよい。]
[0078] ブロック１１１８の別の設計において、第２のパケットは、第１のシーケンス番号よりも後の第３のシーケンス番号で再割り当てされてもよい。第２のパケットは、受信エンティティへの送信のために、第３のシーケンス番号により処理されてもよい。第３のシーケンス番号を有する第３のパケットが、その後受信されるかもしれず、第３のシーケンス番号を有する第３のパケットは、第３のシーケンス番号よりも後の第４のシーケンス番号で再割り当てされてもよい。第３のパケットは、受信エンティティへの送信のために、第４のシーケンス番号により処理されてもよい。]
[0079] 図１２は、ワイヤレス通信システムにおいてパケットを送る装置１２００の設計を示す。装置１２００は、第１のシーケンス番号を有する第１のパケットを受信するモジュール１２１２と、受信エンティティへの送信のために第１のパケットを処理するモジュール１２１４と、第１のシーケンス番号よりも早い第２のシーケンス番号を有する第２のパケットを受信するモジュールであって、第２のパケットは、第１のパケットに対して順序が狂って受信されるモジュール１２１６と、受信エンティティへの送信のために第２のパケットを処理するモジュールであって、第２のパケットは、第２のパケットが第１のパケットよりも後であるかのように処理されるモジュール１２１８とを含む。] 図１２
[0080] 図１３は、ワイヤレス通信システムにおいてパケットを受信するためのプロセス１３００の設計を示す。パケットのシーケンスが、ＵＥにおいてターゲット基地局から受信されてもよい（ブロック１３１２）。パケットのシーケンスは、ソース基地局からターゲット基地局へのＵＥのハンドオーバの間にソース基地局によりターゲット基地局に転送されてもよい。ターゲット基地局は、（ｉ）ＵＥに順に送ることができない、少なくとも１つの転送されたパケットを廃棄するか、または、（ｉｉ）転送されたパケットを順序が狂って受信して、ＵＥへの送信に先立ってパケットを再順序付けするか、または、（ｉｉｉ）転送されたパケットを順序が狂って受信して、それが順に受信されたかのように、パケットを処理してもよい。] 図１３
[0081] シーケンス中の各パケットを処理して、パケットを回復してもよい（ブロック１３１４）。１つの設計において、シーケンス中の先行するパケットのシーケンス番号よりも小さいシーケンス番号をパケットが有する場合、ＨＦＮをインクリメントしてもよい。パケットは、ＨＦＮと、パケットのシーケンス番号とを含むカウントにより解読してもよい。受信したパケットを上位レイヤに引き渡してもよい。回復した１つ以上のパケットを上位レイヤに順序が狂って引き渡してもよい。上位レイヤは、回復したパケット中のデータを再順序付けしてもよい。]
[0082] 図１４は、ワイヤレス通信システムにおいてパケットを送る装置１４００の設計を示す。装置１４００は、ＵＥにおける、ターゲット基地局からパケットのシーケンスを受信するモジュール１４１２と、シーケンス中の各パケットを処理して、パケットを回復するモジュール１４１４とを含む。] 図１４
[0083] 図８、１０、１２および１４におけるモジュールは、プロセッサ、電子デバイス、ハードウェアデバイス、電子コンポーネント、論理回路、メモリなど、または、これらの任意の組み合わせを備えていてもよい。] 図８
[0084] 図１５は、ＵＥ１１０、ソースｅＮＢ／基地局１２０およびターゲットｅＮＢ／基地局１２２の設計のブロック図を示す。ソースｅＮＢ１２０において、送信プロセッサ１５１４ａが、データ源１５１２ａからトラフィックデータと、制御装置／プロセッサ１５３０ａおよびスケジューラ１５３４ａから制御情報とを受け取ってもよい。制御装置／プロセッサ１５３０ａは、ＵＥ１２０のハンドオーバに対するメッセージを提供してもよい。スケジューラ１５３４ａは、ＵＥ１２０に対してダウンリンクおよび／またはアップリンクリソースの割当てを提供してもよい。送信プロセッサ１５１４ａは、トラフィックデータ、制御情報およびパイロットを処理し（例えば、エンコードしてシンボルマッピングし）、それぞれ、データシンボル、制御シンボルおよびパイロットシンボルを提供してもよい。変調器（ＭＯＤ）１５１６ａは、（例えば、ＯＦＤＭに対して）データシンボル、制御シンボルおよびパイロットシンボルを処理して、出力サンプルを提供してもよい。送信機（ＴＭＴＲ）１５１８ａは、出力サンプルを調整して（例えば、アナログに変換し、増幅し、フィルタリングし、アップコンバートし）、アンテナ１５２０ａを通して送信してもよいダウンリンク信号を発生させてもよい。] 図１５
[0085] ターゲットｅＮＢ１２２は、ｅＮＢによってサーブされるＵＥに対するトラフィックデータおよび制御情報を同様に処理してもよい。トラフィックデータ、制御情報およびパイロットは、送信プロセッサ１５１４ｂにより処理され、さらに、変調器１５１６ｂにより処理され、送信機１５１８ｂにより調整され、アンテナ１５２０ｂを通して送信されてもよい。]
[0086] ＵＥ１１０において、アンテナ１５５２は、ｅＮＢ１２０および１２２からダウンリンク信号を受信してもよい。受信機（ＲＣＶＲ）１５５４は、アンテナ１５５２からの受信信号を調整し（例えば、フィルタリングし、増幅し、ダウンコンバートし、デジタル化し）、入力サンプルを提供してもよい。復調器（ＤＥＭＯＤ）１５５６は、（例えば、ＯＦＤＭに対して）入力サンプルを処理して、検出されたシンボルを提供してもよい。受信プロセッサ１５５８は、検出されたシンボルを処理し（例えば、シンボルデマップしてデコードし）、デコードされたトラフィックデータをデータシンク１５６０に提供し、デコードされた制御情報を制御装置／プロセッサ１５７０に提供してもよい。]
[0087] アップリンク上で、送信プロセッサ１５８２は、データ源１５８０からトラフィックデータと、制御装置／プロセッサ１５７０から（例えば、ハンドオーバに対する）制御情報とを受け取って処理してもよい。変調器１５８４は、（例えば、ＳＣ−ＦＤＭに対して）プロセッサ１５８２からのシンボルを処理して、出力シンボルを提供してもよい。送信機１５８６は、出力サンプルを調整し、アンテナ１５５２を通して送信してもよいアップリンク信号を発生させてもよい。各ｅＮＢにおいて、ＵＥ１１０および他のＵＥからのアップリンク信号を、アンテナ１５２０により受信し、受信機１５４０により調整し、復調器１５４２により復調し、受信プロセッサ１５４４により処理してもよい。プロセッサ１５４４は、デコードされたトラフィックデータをデータシンク１５４６に、デコードされた制御情報を制御装置／プロセッサ１５３０に提供してもよい。]
[0088] 制御装置／プロセッサ１５３０ａ、１５３０ｂ、および１５７０は、それぞれ、ｅＮＢ１２０、ｅＮＢ１２２およびＵＥ１１０における動作を指示する。各ｅＮＢにおける制御装置／プロセッサ１５３０はまた、図７におけるプロセス７００、図９におけるプロセス９００、図１１におけるプロセス１１００、および／または、ここで記述した技術に対する他のプロセスを実行または指示してもよい。ＵＥ１１０における制御装置／プロセッサ１５７０は、図１３におけるプロセス１３００、および／または、ここで記述した技術に対する他のプロセスを実行または指示してもよい。メモリ１５３２ａ、１５３２ｂおよび１５７２は、それぞれ、ｅＮＢ１２０、ｅＮＢ１２２およびＵＥ１１０に対するデータおよびプログラムコードを記憶してもよい。スケジューラ１５３４ａおよび１５３４ｂは、それぞれ、ｅＮＢ１２０および１２２との通信のために、ＵＥをスケジュールしてもよく、スケジュールされるＵＥに対してリソースを割り当ててもよい。] 図１１ 図１３ 図７ 図９
[0089] さまざまな異なる技術および技法のうちのいずれかを使用して、情報および信号を表してもよいことを、当業者は理解するだろう。例えば、上記の記述全体を通して参照した、データ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁気フィールドまたは磁気粒子、光学フィールドまたは光学微粒子、あるいはこれらの任意の組み合わせによって表されてもよい。]
[0090] ここでの開示に関連して記述した、さまざまな実例となる論理ブロック、モジュール、回路およびアルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、あるいは両方を組み合わせたものとして実現されてもよいことを、当業者はさらに認識するだろう。ハードウェアおよびソフトウェアのこの互換性を明確に説明するために、さまざまな実例となるコンポーネント、ブロック、モジュール、回路およびステップを、一般的に、これらの機能性の観点から先に記述している。このような機能性が、ハードウェアまたはソフトウェアとして実現されるか否かは、特定のアプリケーションおよびシステム全体に課される設計制約に依存する。熟練者が、それぞれの特定のアプリケーションの方法を変えて、記述した機能性を実現するかもしれないが、このような構成の決定は、本開示の範囲から逸脱を生じさせるものとして解釈されるべきでない。]
[0091] ここでの開示に関連して記述した、さまざまな実例となる論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここで記述した機能を実行するように設計されたこれらの任意の組み合わせにより、実現されるか、あるいは、実行されてもよい。汎用プロセッサはマイクロプロセッサであってもよいが、代わりに、プロセッサは、何らかの従来のプロセッサ、制御装置、マイクロ制御装置、または状態遷移機械であってもよい。プロセッサはまた、コンピューティングデバイスの組み合わせとして、例えば、ＤＳＰとマイクロプロセッサとの組み合わせとして、複数のマイクロプロセッサとして、ＤＳＰコアに関連した１つ以上のマイクロプロセッサとして、あるいは、このような構成の他の何らかの構成として実現されてもよい。]
[0092] ここでの開示に関して記述した方法またはアルゴリズムのステップを、ハードウェア中で直接、プロセッサにより実行されるソフトウェアモジュール中で、またはその２つの組み合わせ中で具体化してもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバルディスク、ＣＤ−ＲＯＭ，または技術的に知られている他の任意の形態の記憶媒体中に存在してもよい。プロセッサが記憶媒体から情報を読み取ることができ、記憶媒体に情報を書き込むことができるように、例示的な記憶媒体はプロセッサに結合されている。代わりに、記憶媒体はプロセッサと一体化されていてもよい。プロセッサおよび記憶媒体は、ＡＳＩＣ中に存在してもよい。ＡＳＩＣはユーザ端末中に存在してもよい。代わりに、プロセッサおよび記憶媒体は、ユーザ端末中にディスクリートコンポーネントとして存在してもよい。]
[0093] １つ以上の例示的な設計において、記述した機能は、ハードウェア、ソフトウェア、ファームウェア、または、これらの任意の組み合せにおいて実現してもよい。ソフトウェアで実現される場合、機能は、１つ以上の命令またはコードとしてコンピュータ読み取り可能媒体上に記憶されてもよければ、あるいは、１つ以上の命令またはコードとしてコンピュータ読み取り可能媒体に対して送信されてもよい。コンピュータ読み取り可能媒体は、１つの場所から別の場所へコンピュータプログラムの転送を促進する何らかの媒体を含むコンピュータ記憶媒体および通信媒体の両方を含む。記憶媒体は、汎用目的又は特定目的のコンピュータによってアクセスできる何らかの利用可能媒体であってもよい。一例として、このようなコンピュータ読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは汎用目的または特定目的のコンピュータによってアクセスできる命令またはデータ構造の形態で所望のプログラムコードを伝送または記憶するために使用できる他の何らかの媒体を含んでいてもよいが、これらに限定されない。また、いくつかの接続は、コンピュータ読み取り可能媒体と適切に呼ばれている。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア線、デジタル加入者線（ＤＳＬ）、または、赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して、ウェブサイト、サーバまたは他のリモート情報源から送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア線、ＤＳＬ、または、赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。ここで使用されるディスク（Ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタルバーサタイルディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ディスク（ｄｉｓｋ）は通常、磁気的にデータを再生し、一方、ディスク（ｄｉｓｃ）は、レーザにより光学的にデータを再生する。上述の組み合わせもまた、コンピュータ読み取り可能媒体の範囲内に含まれるべきである。]
[0094] いかなる当業者であっても本開示を実施しまたは使用できるように、本開示の記述をこれまでに提供している。本開示に対してさまざまな修正が当業者に容易に明らかであり、本開示の精神または範囲から逸脱することなく、ここで規定した一般的な原理を、他のバリエーションに適用してもよい。したがって、本開示は、ここで記述した例および設計に限定されるように意図されていないが、ここで開示した原理および新規な特徴に矛盾しない最も広い範囲に一致すべきである。]

权利要求:

請求項1
ワイヤレス通信のための方法において、第２のエンティティにおいて、第１のエンティティからパケットのシーケンスを受信することと、前記シーケンス中の各パケットを第３のエンティティに順に送ることができるかどうかを決定することと、順に送ることができる各パケットを前記第３のエンティティに送ることと、順に送ることができない各パケットを廃棄することとを含む方法。
請求項2
前記第１のエンティティはソース基地局であり、前記第２のエンティティはターゲット基地局であり、前記第３のエンティティはユーザ機器（ＵＥ）であり、前記受信することと、前記決定することと、前記送ることと、前記廃棄することとは、前記ソース基地局から前記ターゲット基地局への前記ＵＥのハンドオーバの間に前記ターゲット基地局により実行される請求項１記載の方法。
請求項3
前記シーケンス中の各パケットを順に送ることができるかどうかを決定することは、前記第３のエンティティに送られた最後のパケットのシーケンス番号に対してポインタを維持することと、前記各パケットのシーケンス番号と前記ポインタとに基づいて、前記シーケンス中の各パケットを前記第３のエンティティに順に送ることができるかどうかを決定することとを含む請求項１記載の方法。
請求項4
前記シーケンス中の各パケットを順に送ることができるかどうかを決定することは、パケットが、前記第３のエンティティにすでに送られているパケットのシーケンス番号よりも早いシーケンス番号を有する場合、前記パケットを前記第３のエンティティに順に送ることができないことを決定することを含む請求項１記載の方法。
請求項5
前記決定することと、前記送ることと、前記廃棄することとは、前記シーケンス中の各パケットが前記第１のエンティティから受信されるときに、前記第２のエンティティにおいて前記パケットをバッファに入れることなく実行される請求項１記載の方法。
請求項6
前記パケットのシーケンスは、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）サービスデータユニット（ＳＤＵ）のシーケンスを含む請求項１記載の方法。
請求項7
前記パケットのシーケンスを受信することは、パケット交換インターフェースを通して前記第１のエンティティから前記パケットのシーケンスを受信することを含む請求項１記載の方法。
請求項8
ワイヤレス通信のための装置において、第２のエンティティにおいて、第１のエンティティからパケットのシーケンスを受信し、前記シーケンス中の各パケットを第３のエンティティに順に送ることができるかどうかを決定し、順に送ることができる各パケットを前記第３のエンティティに送り、順に送ることができない各パケットを廃棄するように構成されている少なくとも１つのプロセッサを具備する装置。
請求項9
前記少なくとも１つのプロセッサは、前記第３のエンティティに送られた最後のパケットのシーケンス番号に対してポインタを維持し、前記各パケットのシーケンス番号と前記ポインタとに基づいて、前記シーケンス中の各パケットを前記第３のエンティティに順に送ることができるかどうかを決定するように構成されている請求項８記載の装置。
請求項10
前記少なくとも１つのプロセッサは、前記第３のエンティティにすでに送られているパケットのシーケンス番号よりも早いシーケンス番号をパケットが有する場合、前記パケットを前記第３のエンティティに順に送ることができないことを決定するように構成されている請求項８記載の装置。
請求項11
ワイヤレス通信のための装置において、第２のエンティティにおいて、第１のエンティティからパケットのシーケンスを受信する手段と、前記シーケンス中の各パケットを第３のエンティティに順に送ることができるかどうかを決定する手段と、順に送ることができる各パケットを前記第３のエンティティに送る手段と、順に送ることができない各パケットを廃棄する手段とを具備する装置。
請求項12
前記シーケンス中の各パケットを順に送ることができるかどうかを決定する手段は、前記第３のエンティティに送られた最後のパケットのシーケンス番号に対してポインタを維持する手段と、前記各パケットのシーケンス番号と前記ポインタとに基づいて、前記シーケンス中の各パケットを前記第３のエンティティに順に送ることができるかどうかを決定する手段とを備える請求項１１記載の装置。
請求項13
前記シーケンス中の各パケットを順に送ることができるかどうかを決定する手段は、パケットが、前記第３のエンティティにすでに送られているパケットのシーケンス番号よりも早いシーケンス番号を有する場合、前記パケットを前記第３のエンティティに順に送ることができないことを決定する手段を備える請求項１１記載の装置。
請求項14
コンピュータプログラムプロダクトにおいて、コンピュータ読み取り可能媒体を具備し、前記コンピュータ読み取り可能媒体は、第２のエンティティにおいて、第１のエンティティからパケットのシーケンスを受信することを少なくとも１つのコンピュータに生じさせるためのコードと、前記シーケンス中の各パケットを第３のエンティティに順に送ることができるかどうかを決定することを前記少なくとも１つのコンピュータに生じさせるためのコードと、順に送ることができる各パケットを前記第３のエンティティに送ることを前記少なくとも１つのコンピュータに生じさせるためのコードと、順に送ることができない各パケットを廃棄することを前記少なくとも１つのコンピュータに生じさせるためのコードとを含むコンピュータプログラムプロダクト。
請求項15
ワイヤレス通信のための方法において、第２のエンティティにおいて、第１のエンティティからパケットのシーケンスを受信することと、前記シーケンス中のパケットを再順序付けすることと、前記第２のエンティティから第３のエンティティに、前記再順序付けされたパケットを送ることとを含む方法。
請求項16
前記第１のエンティティはソース基地局であり、前記第２のエンティティはターゲット基地局であり、前記第３のエンティティはユーザ機器（ＵＥ）であり、前記受信することと、前記受信することと、前記再順序付けすることと、前記送ることとは、前記ソース基地局から前記ターゲット基地局への前記ＵＥのハンドオーバの間に前記ターゲット基地局により実行される請求項１５記載の方法。
請求項17
前記パケットのシーケンスは、再順序付け窓により決定されている時間期間の間に、前記第２のエンティティにより受信される請求項１５記載の方法。
請求項18
前記パケットを再順序付けすることは、前記第１のエンティティから前記シーケンス中の最初のパケットを受信することに応答して、タイマを開始することと、前記第１のエンティティから順に受信されなかった場合、前記最初のパケットをバッファに入れることと、前記タイマの満了前に、前記第１のエンティティから順に受信されなかった後続のパケットをバッファに入れることと、前記タイマの満了後に、前記バッファに入れられたパケットを再順序付けすることとを含む請求項１５記載の方法。
請求項19
前記タイマの満了後に前記第１のエンティティから受信した各パケットをバッファに入れることなく、前記各パケットを処理することをさらに含む請求項１８記載の方法。
請求項20
前記タイマの満了後に前記第１のエンティティからパケットを受信することと、前記パケットを前記第３のエンティティに順に送ることができるかどうかを決定することと、前記パケットを順に送ることができる場合、前記パケットを前記第３のエンティティに送ることと、順に送ることができない場合、前記パケットを廃棄することとをさらに含む請求項１８記載の方法。
請求項21
ワイヤレス通信のための装置において、第２のエンティティにおいて、第１のエンティティからパケットのシーケンスを受信し、前記シーケンス中のパケットを再順序付けし、前記第２のエンティティから第３のエンティティに、前記再順序付けされたパケットを送るように構成されている少なくとも１つのプロセッサを具備する装置。
請求項22
前記少なくとも１つのプロセッサは、前記第１のエンティティから前記シーケンス中の最初のパケットを受信することに応答して、タイマを開始し、前記第１のエンティティから順に受信されなかった場合、前記最初のパケットをバッファに入れ、前記タイマの満了前に、前記第１のエンティティから順に受信されなかった後続のパケットをバッファに入れ、前記タイマの満了後に、前記バッファに入れられたパケットを再順序付けするように構成されている請求項２１記載の装置。
請求項23
前記少なくとも１つのプロセッサは、前記タイマの満了後に前記第１のエンティティから受信した各パケットをバッファに入れることなく、前記各パケットを処理するように構成されている請求項２２記載の装置。
請求項24
前記少なくとも１つのプロセッサは、前記タイマの満了後に前記第１のエンティティからパケットを受信し、前記パケットを前記第３のエンティティに順に送ることができるかどうかを決定し、前記パケットを順に送ることができる場合、前記パケットを前記第３のエンティティに送り、順に送ることができない場合、前記パケットを廃棄するように構成されている請求項２２記載の装置。
請求項25
ワイヤレス通信のための方法において、第１のシーケンス番号を有する第１のパケットを受信することと、受信エンティティへの送信のために前記第１のパケットを処理することと、前記第１のシーケンス番号よりも早い第２のシーケンス番号を有する第２のパケットを受信し、前記第２のパケットは、前記第１のパケットに対して順序が狂って受信されることと、前記受信エンティティへの送信のために前記第２のパケットを処理し、前記第２のパケットは、前記第２のパケットが前記第１のパケットよりも後であるかのように処理されることとを含む方法。
請求項26
前記受信エンティティはユーザ機器（ＵＥ）であり、前記第１および第２のパケットは、ソース基地局からターゲット基地局への前記ＵＥのハンドオーバの間に前記ソース基地局により前記ターゲット基地局に転送される請求項２５記載の方法。
請求項27
前記順序が狂って第２のパケットを受信することに応答して、ハイパーフレーム番号（ＨＦＮ）をインクリメントすることをさらに含み、前記ＨＦＮは、前記第２のパケットを処理するために使用される請求項２５記載の方法。
請求項28
前記第１のパケットを処理することは、ハイパーフレーム番号（ＨＦＮ）と、前記第１のシーケンス番号とを含む第１のカウントにより前記第１のパケットを暗号化することを含み、前記第２のパケットを処理することは、前記順序が狂って第２のパケットを受信することに応答して、前記ＨＦＮをインクリメントすることと、前記インクリメントされたＨＦＮと、前記第２のシーケンス番号とを含む第２のカウントにより前記第２のパケットを暗号化することとを含む請求項２５記載の方法。
請求項29
前記第２のパケットを処理することは、前記第１のシーケンス番号よりも後の第３のシーケンス番号で前記第２のパケットを再割り当てすることと、前記受信エンティティへの送信のために、前記第３のシーケンス番号を有する前記第２のパケットを処理することとを含む請求項２５記載の方法。
請求項30
前記第３のシーケンス番号を有する第３のパケットを受信することと、前記第３のシーケンス番号よりも後の第４のシーケンス番号で前記第３のパケットを再割り当てすることと、前記受信エンティティへの送信のために、前記第４のシーケンス番号を有する前記第３のパケットを処理することとをさらに含む請求項２９記載の方法。
請求項31
前記第１および第２のパケットは、各パケットが受信されるときに、前記第１および第２のパケットをバッファに入れることなく処理される請求項２５記載の方法。
請求項32
ワイヤレス通信のための装置において、第１のシーケンス番号を有する第１のパケットを受信し、受信エンティティへの送信のために前記第１のパケットを処理し、前記第１のシーケンス番号よりも早い第２のシーケンス番号を有する第２のパケットを受信し、前記第２のパケットが前記第１のパケットよりも後であるかのように、前記受信エンティティへの送信のために前記第２のパケットを処理するように構成されている少なくとも１つのプロセッサを具備し、前記第２のパケットは、前記第１のパケットに対して順序が狂って受信される装置。
請求項33
前記少なくとも１つのプロセッサは、ハイパーフレーム番号（ＨＦＮ）と、前記第１のシーケンス番号とを含む第１のカウントにより前記第１のパケットを暗号化し、前記順序が狂って第２のパケットを受信することに応答して、前記ＨＦＮをインクリメントし、前記インクリメントされたＨＦＮと、前記第２のシーケンス番号とを含む第２のカウントにより前記第２のパケットを暗号化するように構成されている請求項３２記載の装置。
請求項34
前記少なくとも１つのプロセッサは、前記第１のシーケンス番号よりも後の第３のシーケンス番号により前記第２のパケットを再割り当てし、前記受信エンティティへの送信のために、前記第３のシーケンス番号を有する前記第２のパケットを処理するように構成されている請求項３２記載の装置。
請求項35
ワイヤレス通信のための方法において、ユーザ機器（ＵＥ）において、ターゲット基地局からパケットのシーケンスを受信し、前記パケットのシーケンスは、ソース基地局から前記ターゲット基地局への前記ＵＥのハンドオーバの間に前記ソース基地局により前記ターゲット基地局に転送され、前記ターゲット基地局は、前記ＵＥに順に送ることができない、少なくとも１つの転送されたパケットを廃棄するか、または、転送されたパケットを順序が狂って受信して、前記ＵＥへの送信に先立って前記パケットを再順序付けするか、または、転送されたパケットを順序が狂って受信して、順に受信されたかのように前記パケットを処理することと、前記シーケンス中の各パケットを処理して、前記パケットを回復することとを含む方法。
請求項36
前記シーケンス中の各パケットを処理することは、前記パケットが、前記シーケンス中の先行するパケットのシーケンス番号よりも小さいシーケンス番号を有する場合、ハイパーフレーム番号（ＨＦＮ）をインクリメントすることと、前記ＨＦＮと、前記パケットのシーケンス番号とを含むカウントにより、前記パケットを解読することとを含む請求項３５記載の方法。
請求項37
前記シーケンス中の回復されたパケットを上位レイヤに引き渡し、少なくとも１つの回復されたパケットは、前記上位レイヤに順序が狂って引き渡されることと、前記上位レイヤにおいて、前記回復されたパケット中のデータを再順序付けすることとをさらに含む請求項３５記載の方法。
請求項38
ワイヤレス通信のための装置において、ユーザ機器（ＵＥ）において、ターゲット基地局からパケットのシーケンスを受信し、前記シーケンス中の各パケットを処理して、前記パケットを回復するように構成されている少なくとも１つのプロセッサを具備し、前記パケットのシーケンスは、ソース基地局から前記ターゲット基地局への前記ＵＥのハンドオーバの間に前記ソース基地局により前記ターゲット基地局に転送され、前記ターゲット基地局は、前記ＵＥに順に送ることができない、少なくとも１つの転送されたパケットを廃棄するか、または、転送されたパケットを順序が狂って受信して、前記ＵＥへの送信に先立って前記パケットを再順序付けするか、または、転送されたパケットを順序が狂って受信して、順に受信されたかのように前記パケットを処理する装置。
請求項39
前記シーケンス中の各パケットに対して、前記少なくとも１つのプロセッサは、前記パケットが前記シーケンス中の先行するパケットのシーケンス番号よりも小さいシーケンス番号を有する場合、ハイパーフレーム番号（ＨＦＮ）をインクリメントし、前記ＨＦＮと、前記パケットのシーケンス番号とを含むカウントにより、前記パケットを解読するように構成されている請求項３８記載の装置。
請求項40
前記少なくとも１つのプロセッサは、前記シーケンス中の回復されたパケットを上位レイヤに引き渡し、少なくとも１つの回復されたパケットを、前記上位レイヤに順序が狂って引き渡し、前記上位レイヤにおいて、前記回復されたパケット中のデータを再順序付けするように構成されている請求項３８記載の装置。